The 3rd Generation Partnership Project, 3GPP specifications have introduced agnostic Internet Protocol (IP) Multi-media Service (IMS) access via an IP Connectivity Access Network (IP-CAN) wherein an IMS enabled terminal may access 3GPP IMS services using various IP-CANs such as, but not limited to, GPRS/UMTS, 3GPP-IWLAN, WLAN direct IP access, etc., and using a variety of radio access technologies such as, but not limited to, UTRAN, GERAN, 802.11, Bluetooth, etc.
In such agnostic IMS access networks, an IMS terminal may obtain an IP address that is routable in the 3GPP PLMN that it's accessing, perform an initial IMS registration/authentication procedure using that address, and the terminal is ready for communication. The IMS network itself does not care whether the address was obtained via a PDP context activation or as a result of IPsec tunnel establishment with a Packet Data Gateway (PDG) or any other IP-CAN specific connection mechanism.
The advent of IP-CAN agnostic IMS access raises the possibility of IMS mobility across heterogeneous IP-CANs and consequently issues relating to IMS service continuity across IP-CANs. One such issue is that changing IP-CANs usually always entails a change in local IP address and, unfortunately, changing IP address while connected to an IMS network is extremely disruptive.
For example, changing the local IP address in the IMS Terminal may result in the following undesirable actions with respect to IMS connectivity and services: loss of all on-going IMS dialogs (i.e., sessions and subscriptions) and transactions; deregistration of all explicitly and implicitly registered public user identities; user re-authentication with IMS core and a establishment of a new set of IPsec Security Associations (SAs) between the IMS Terminal and the network; re-registration of all previously registered public user identities registered with the IMS core using the new IP address; and user re-subscription to the registration event package.
In other words, the current IMS connectivity and services are lost and need to be re-established from scratch. As a result, seamless “make before break” and “break before make” IMS handoff scenarios to a new IP address cannot be supported using the current IMS functionality.
Some suggested solutions for achieving service continuity in IMS networks revolve around the use of Mobile IP to support mobility at the IP layer between various IP-CANs. However, Mobile IP supports mobility for scenarios in which a mobile terminal needs to move between different network domains, but does not require a corresponding change to the SIP proxy. In order to change proxies, the mobile requires application (i.e. IMS) layer mobility and not network layer mobility as supported by Mobile IP.
An additional shortcoming of Mobile IP, with respect to IMS service continuity, is that Mobile IP only supports the movement of “all” the mobile's dialogs and sessions from one local IP connection to another. While this is desirable in many scenarios there are other scenarios where the mobile may need to move only a specific subset of its dialogs and sessions from one local IP connection to another. In order to manage the mobility of specific dialogs and sessions, the mobile requires application (i.e. IMS) layer mobility and not network layer mobility as supported by Mobile IP.
Thus there is a need to extend an IMS network to allow an IMS terminal to establish new connections to the IMS network via different local IP connections and to move existing IMS registration bindings and sessions to those new IMS connections with minimal disruption to the user such that service continuity may be achieved.